sorry if this isn't the correct place to post this type of question but I have a question regarding best practices in content schema design using Umbraco. Basically, I've started developing a webapplication using Umbraco 7.2 and I've reached a point where I need to store a few lists of things that aren't neccessarily related to the webapplication itself, things like a list of projects, a list of clients, invoices and so on.
Normally, I would create a database schema and populate it with the data and simply query and display it but this would completely bypass Umbraco. My question is, how do you guys normally approach this kind of problem? I thought about simply creating document types for each type (e.g. Client, Project, Invoice) with custom properties representing the fields I would normally store in the database and create all of them as Content nodes. My only concern with this is that the application may well have 100+ clients and projects etc, which could clutter up the Content Tree.
Am I missing some clever Umbraco way of doing this kind of thing?
I understand that obviously this can come down to personal preference, but I'm eager to hear your opinion as I'm somewhat new to using Umbraco for this type of project!
You can handle this outside of Umbraco if you would like. To me it does not sound like something that needs to be in the tree. I prefer using Umbraco for what's relevant to display on the website and let i handle web-content, which can be either pages or content elements.
So you can make up some custom code that lives side-by-side with you Umbraco application - You just need to add some paths to the reserved urls path in the web.config.
You can also choose to add a custom section to Umbraco where you can create your own trees for dealing with this extending the database with the tables needed and then using angularjs based controllers and views in the Umbraco backoffice exposing the data using WebApi.
To get an idea about this I think you should try reading the blogpost written by Tim Geyssens here http://www.nibble.be/?p=440
But you're right the above does not belong in the content section and just because you could create it there does not mean that you should.
thanks for the reply! I think you might be right that the best approach is to simply handle it outside Umbraco, although the approach of creating custom trees and sections in the Backoffice seems pretty good too. I did find one way which seems "okay" and that is to create a root content element for each of the categories and set the corresponding data types to be children of that node, so the structure becomes something like this:
- Home - Actual webcontent - more pages etc. - Invoices - Projects - Clients
Due to the nature of the Umb7 backoffice the child elements in the Invoices, Projects and Clients lists don't appear so the clutter isn't too bad. Clicking either of the three shows the table of all the child nodes which has the table sorting and search functionality to make it somewhat user friendly.
What do you think of this approach? Will it run into issues with lots of content?
As I mentioned above...if it's not content that is in any way relevant to the website, like pages or elements that represents content that you want to display on the website then I don't think that it belongs in the content section. Then I think the approach of handling it in a custom section is much better so the content section is only used for the website content :)
It's not that you can't do it like you have sketched above I just don't think it's a good idea to do it in that way.
Content design question [architecture]
Hey guys,
sorry if this isn't the correct place to post this type of question but I have a question regarding best practices in content schema design using Umbraco. Basically, I've started developing a webapplication using Umbraco 7.2 and I've reached a point where I need to store a few lists of things that aren't neccessarily related to the webapplication itself, things like a list of projects, a list of clients, invoices and so on.
Normally, I would create a database schema and populate it with the data and simply query and display it but this would completely bypass Umbraco. My question is, how do you guys normally approach this kind of problem? I thought about simply creating document types for each type (e.g. Client, Project, Invoice) with custom properties representing the fields I would normally store in the database and create all of them as Content nodes. My only concern with this is that the application may well have 100+ clients and projects etc, which could clutter up the Content Tree.
Am I missing some clever Umbraco way of doing this kind of thing?
I understand that obviously this can come down to personal preference, but I'm eager to hear your opinion as I'm somewhat new to using Umbraco for this type of project!
Thanks in advance,
Hi Jtdrup
You can handle this outside of Umbraco if you would like. To me it does not sound like something that needs to be in the tree. I prefer using Umbraco for what's relevant to display on the website and let i handle web-content, which can be either pages or content elements.
So you can make up some custom code that lives side-by-side with you Umbraco application - You just need to add some paths to the reserved urls path in the web.config.
You can also choose to add a custom section to Umbraco where you can create your own trees for dealing with this extending the database with the tables needed and then using angularjs based controllers and views in the Umbraco backoffice exposing the data using WebApi.
To get an idea about this I think you should try reading the blogpost written by Tim Geyssens here http://www.nibble.be/?p=440
But you're right the above does not belong in the content section and just because you could create it there does not mean that you should.
I hope this helps a bit.
/Jan
Hey Jan,
thanks for the reply! I think you might be right that the best approach is to simply handle it outside Umbraco, although the approach of creating custom trees and sections in the Backoffice seems pretty good too. I did find one way which seems "okay" and that is to create a root content element for each of the categories and set the corresponding data types to be children of that node, so the structure becomes something like this:
- Home
- Actual webcontent
- more pages etc.
- Invoices
- Projects
- Clients
Due to the nature of the Umb7 backoffice the child elements in the Invoices, Projects and Clients lists don't appear so the clutter isn't too bad. Clicking either of the three shows the table of all the child nodes which has the table sorting and search functionality to make it somewhat user friendly.
What do you think of this approach? Will it run into issues with lots of content?
Hi Jtdrup
As I mentioned above...if it's not content that is in any way relevant to the website, like pages or elements that represents content that you want to display on the website then I don't think that it belongs in the content section. Then I think the approach of handling it in a custom section is much better so the content section is only used for the website content :)
It's not that you can't do it like you have sketched above I just don't think it's a good idea to do it in that way.
/Jan
I think you're right, thanks for your insight!
is working on a reply...